Web services networks are rapidly evolving technology architectures allowing applications to tap into a variety of services in an extremely efficient and cost effective manner. Web services enable cost-effective and efficient collaboration among entities within an enterprise or across enterprises. Web or application services are network addressable computing resources that exchange data and execute processes. Essentially, Web services are applications exposed as services over a computer network and employed by other applications using Internet standard technologies, such as XML, SOAP, WSDL, etc. Accordingly, Web applications can be quickly and efficiently assembled with services available within an enterprise LAN or external services available over open computer networks, such as the Internet.
A Web services network can be deployed across an enterprise LAN or across a Wide Area Network, such as the Internet. A typical Web services network includes at least one network services broker that is operative to receive a service request and route the service request to the appropriate resource. A broker is a specially configured server or cluster of servers acting as an intermediary for Web service requests and responses. As Web services network usage increases, however, the broker can become a bottleneck. To ease this bottleneck, the prior art solution is simply to add additional processing power to the broker (e.g., additional servers), which is costly, inefficient, and fails to leverage the enterprise's investments in its existing network infrastructure. Moreover, the centralized nature of the broker creates reliability concerns in that failure of the broker disables the applications accessing services through it. Accordingly, U.S. application Ser. No. 09/990,722 discloses a distributed Web services network architecture that, among other things, alleviates the bottleneck and point-of-failure concerns discussed above.
The Interface Definition Language (IDL) was introduced in the early 1990s by a consortium of large corporations known as the Object Management Group (OMG). The purpose of IDL was to provide a standard platform- and language-independent grammar by which the interfaces used to connect software components are described. IDL became one of the cornerstones of CORBA technology, and variants such as MIDL (developed by Microsoft® Corporation) have been used to describe the interfaces employed by a number of other component architectures. The emergence of Web services spurred the creation of a conceptually and syntactically similar interface description language, Web Services Description Language (WSDL), intended to address the unique issues associated with Web-based protocols.
WSDL has been widely adopted and is currently the de facto industry-wide standard for Web service interface definition. All commercial Web service toolkits support WSDL consumption and/or generation at least to some extent. Current Web services functionality includes the ability to do one or more of the following tasks with respect to WSDL:                Consume a WSDL document, generating a Web service request template or a source code skeleton to be used for generating a request and consuming a response.        Consume a WSDL document, generating a source code skeleton for responding to Web service requests defined in that document.        Generate a WSDL document, based on the low-level interfaces implicit in a source code module.        Place WSDL in a repository, sometimes based on Universal Description, Discovery, and Integration (UDDI), and provide access to that repository to interested parties.WSDL documents are static—that is, once generated or stored in a registry they are treated essentially like any other block of text, where all information presented in the WSDL document is assumed to be immutable. Accordingly, changes to the underlying Web service associated with a WSDL document requires corresponding changes to the WSDL document and any applications that consume this Web service. For example, consider the situation where a materials company has located a Web service at www.chemco.com/ws/aluminum oxides. The endpoint is duly noted in the service's WSDL document, which is in turn imported by a number of client applications. This arrangement initially works as intended; however, several months after the service is introduced, another enterprise “Acquiring Chemical Co.” acquires the business unit offering the web service. Acquiring Chemical Co. is naturally averse to using the “Chemco” name in its URLs, and wishes to deploy the service onto www.acquiringchemcoIT/services/materials:7001. This presents a serious problem in that the client applications using the service have acquired the WSDL containing the endpoint location as a static document, and will continue to use the originally specified endpoint unless additional measures are undertaken.        
In light of the foregoing, a need in the art exists for methods, apparatuses and systems that allow Web service application to dynamically adapt to changes in Web services. In addition, a need in the art exists for methods, apparatuses and systems facilitating the virtualization of web services. A need further exists in the art for methods, apparatuses and systems facilitating the dynamic provisioning of web services. A need also exists in the art for methods, apparatuses and systems allowing for the instancing of web services. Embodiments of the present invention substantially fulfill these needs.